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ZNTRODaCTZON 


This  report  provides  an  overview  and  concept  evaluation  of  the 
Deployment  Analysis  Prototype  (DAP) .  Section  l  considers  the 
DAP  in  the  context  of  the  deployment  planning  environment. 
Section  2  provides  an  overview  and  evaluation  of  the  DAP 
structures  as  well  as  specific  algorithmic,  computer,  and 
interface  issues.  Sections  2  and  3  also  provide  recommen¬ 
dations  for  improvement  of  the  DAP. 


2  DEPLOYMENT  PLANNING 

2.1  Deployaent  Planning  Environment 

2.1.1  Variation  in  Size  and  Time  Frame 

The  size  of  a  deployment  ranges  from  the  movement  of  a  small 
rescue  teaun  to  the  movement  of  millions  of  tons  of  material 
for  the  reinforcement  of  Europe.  Movement  of  a  small  rescue 
team  may  take  only  a  few  hours,  while  reinforcement  of  Europe 
can  take  several  months.  Movement  of  a  small  rescue  team  may 
require  precise  scheduling  to  within  a  few  minutes,  while 
reinforcement  of  Europe  may  only  require  scheduling  by  week. 
Limitation  of  assets  would  not  normally  be  an  issue  with 
movement  of  a  rescue  team,  but  would  be  one  of  the  critical 
factors  in  the  reinforcement  of  Europe. 

Because  the  DAP  is  implemented  on  a  PC,  it  will  be  necessary 
to  (1)  model  relatively  small  deployment  scenarios,  (2) 
consider  a  number  of  small  time  frames,  or  (3)  utilize  a 
fairly  high  level  of  aggregation  of  the  input  data.  As 
currently  constituted,  the  DAP  doesn't  have  the  ability  to 
either  "aggregate"  or  use  "rolling  horizons."  These  are 
features  which  might  be  considered  as  future  enhancements. 
The  current  DAP  seems  most  appropriate  for  smaller  deploy¬ 
ments  . 
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While  much  of  deliberate  planning  assvimes  a  static  environment 
(i.e.,  the  future  is  known  with  certainty),  the  actual 
environment  is  very  dynamic.  At  best  the  future  can  be 
predicted  for  only  a  very  short  horizon.  For  short  duration 
deployments,  such  as  rescue  operations,  reasonably  accurate 
predictions  regarding  availedsility  of  recjuirements  and 
location  of  assets  can  be  expected.  However,  as  the  planning 
horizon  becomes  longer  than  a  few  days,  it  becomes  very 
unlikely  that  the  status  of  the  system  can  be  predicted  with 
much  precision.  Even  if  requirements  remain  as  projected,  it 
seems  very  unlikely  that  scheduled  arrivals  and  departures  of 
ships  and  planes  several  weeks  in  the  future  could  be  closely 
followed. 

The  current  DAP  uses  the  same  level  of  resolution  throughout 
the  horizon.  The  notion  of  varying  resolution  by  time  needs 
further  study.  Its  clear  that  the  assumption  made  in  deliber¬ 
ate  planning  -  that  the  future  is  known  with  certainty  -  can 
cause  problems  for  the  DAP  in  actual  execution  planning. 

2.1.3  Multiple  Decision  Makers 

There  are  a  variety  of  decision  makers  with  only  limited 
central  control.  The  Joint  Chiefs  of  Staff  make  strategic 
decisions  including  whether  or  not  to  undertake  an  operation 
and  what  resources  are  to  be  allocated  to  the  operation.  The 
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supported  commander  makes  decisions  regarding  what  material 
is  required,  where  it  is  required,  when  it  is  required,  and 
what  mode  it  takes.  The  supporting  commanders  make  decisions 
regarding  the  sources  of  these  materials.  USTRANSCOM  makes 
transportation  coordination  decisions.  The  Transportation 
Operating  Agencies  make  decisions  regarding  specific  routing 
and  scheduling. 

The  DAP  is  intended  to  aid  in  making  a  basic  decision  concern¬ 
ing  the  choice  of  mode.  Hence,  in  its  present  form  it  seems 
to  be  a  tool  oriented  to  the  Supported  Commander.  However, 
it  is  not  clear  that  the  DAP  addresses  a  significant  portion 
of  the  decisions  with  which  the  Supported  Commander  is  faced. 

2.2  Types  of  Decisions 

A  useful  way  to  characterize  deployment  related  decisions  is 
in  terms  of  the  time  frame  to  be  considered.  As  the  deploy¬ 
ment  planning  effort  extends  further  into  the  future  then  (1) 
the  degree  of  uncertainty  regarding  data  will  increase,  (2) 
the  level  of  detail  of  available  data  will  decrease,  and  (3) 
the  specificity  of  decisions  will  decrease. 

2.2.1  Short  Term  Decisions 

Examples  of  short  term  decisions  include  specific  scheduling 
and  routing  of  individual  transportation  units  (e.g.,  where 
will  a  ship  load,  when  will  it  load,  what  cargos  will  be 


loaded,  how  will  they  be  loaded,  when  will  it  sail,  and  what 
will  be  its  route?) .  These  decisions  require  very  specific 


detailed  data  regarding  the  ship  and  its  cargos  (e.g.,  for 
planes,  the  items  are  actually  weighed  before  they  are 
loaded) . 


2.2.2  Medium  Term  Decisions 

Examples  of  medivua  term  decisions  include  allocation  of  assets 
to  deployments,  sourcing  of  material,  transportation  mode 
selection,  general  scheduling  and  routing  of  material  move¬ 
ment,  and  general  scheduling  and  routing  of  transportation 
assets.  While  it  would  be  comforting  to  have  precise  detailed 
data  to  support  these  decisions,  the  best  one  can  expect  is 
some  approximation  as  planning  extends  into  the  future. 
Particularly  with  regard  to  time  estimates  (e.g.,  arrival  and 
departure  times  at  ports) ,  estimates  are  not  very  accurate 
except  for  regularly  scheduled  assets.  In  general  reasonably 
accurate  data  will  exist  for  the  near  term  with  diminishing 
accuracy  further  into  the  future. 

2.2.3  Long  Term  Decisions 

Examples  of  long  term  decisions  include  sizing  of  port 
capacity,  acquisition  of  transportation  assets,  acquisition 
and  positioning  of  material,  and  assessing  long  term  strategic 
feasibility.  For  these  decisions  the  available  data  is 


generally  very  aggregate  with  little  resolution  with  regard 
to  timing  issues. 
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2.2.4  B&r-PSSislQQS 

The  level  of  resolution  of  the  data  used  by  the  DAP  seems  most 
appropriate  for  medium  term  decisions.  However,  there  is  some 
inconsistency  between  the  data  resolution  and  the  modeling 
resolution.  (The  modeling  resolution,  for  example,  appears 
to  track  individual  ships . ) 

The  DAP  considers,  to  some  degree,  decisions  such  as  port 
selection,  MR  scheduling,  asset  allocation  and  scheduling. 
In  its  new  role,  USTRANSCOM  should  decide  who  the  ultimate 
user  of  the  DAP  will  be  and  orient  its  decision  support 
capabilities  to  fit  the  needs  of  that  user. 

2.3  Determining  Transportation  Mode 

since  the  primary  focus  of  the  DAP  is  on  model  selection, 
there  are  two  fundamental  questions  it  should  address:  (1)  for 
a  given  mode  assignment  can  everything  be  delivered  as  re- 
q[uested,  and  (2)  if  not,  how  can  mode  assignment  be  altered 
to  deliver  as  much  as  possible  on  time?  If  mode  is  arbitrari¬ 
ly  assigned,  then  the  danger  is  that  an  insufficient  amount 
of  the  assigned  mode  will  be  assigned  to  transport  the 
material  so  that  it  will  arrive  at  the  times  required  but  that 
some  other  mode  assignment  would  allow  all  of  the  movement 


requirements  to  be  transported  on  schedule.  There  is  also  the 
possibility  that  there  is  no  possible  assignment  of  mode  that 
will  allow  all  of  the  movement  requirements  to  be  transported 
on  schedule. 


The  first  natural  question  is  to  determine  if  a  given  mode 
assignment  will  allow  all  of  the  movement  requirements  to  be 
transported  so  that  they  arrive  when  desired.  To  make  this 
determination  it  is  necessary  for  the  system  to  make  at  least 
a  gross  allocation  of  ships  and  planes  to  transportation  legs 
over  time  and  a  gross  routing  of  the  movement  requirements 
through  these  transportation  legs.  The  models  implemented  in 
the  DAP  seem  weak  in  this  regard. 


To  determine  if  a  mode  assignment  is  feasible,  one  might 
consider  simply  assigning  available  assets  to  movement  re¬ 
quirements  according  to  some  schedule ,  ( e . g . , as  they  become 
available  to  move)  as  long  as  the  assignment  would  deliver  the 
movement  requirement  within  the  time  interval  required,  (e.g., 
using  the  route  having  the  minimum  transportation  time) .  In 
doing  this,  there  is  the  danger  is  that  the  movement  require¬ 
ment  schedule  will  cause  the  use  of  transportation  assets  now 
to  move  material  which  is  not  currently  time  critical  and  then 
later  (less  than  one  cycle  later)  have  insufficient  assets  to 
move  material  which  is  time  critical.  This  issue  can  be 


avoided  by  requiring  the  user  to  assign  the  exact  period 
(e.g.,  day,  week,  etc.)  that  he  wants  the  movement  requirement 
to  arrive  at  its  destination.  However,  there  are  also 
questions  of  when  to  dispatch  the  plane  or  ship  if  the 
available  movement  requirements  do  not  constitute  a  full  load, 
how  to  choose  between  different  types  of  ships  and  planes,  and 
how  to  handle  delays  caused  by  ports  being  at  capacity. 
Again,  the  DAP  models  appear  to  require  some  improvement  in 
this  area. 


2.3.2 


Simultaneous  Scheduling  of  Assets  and  MRs 


The  question  of  how  to  optimally  make  an  initial  mode  assign¬ 
ment  or  how  to  improve  a  mode  assignment  which  is  infeasible 
(i.e.,  not  all  movement  requirements  are  delivered  on  time) 
is  extremely  difficult.  In  order  to  optimally  make  a  mode 
assignment,  it  is  necessary  to  simultaneously  consider  both 
air  and  sea,  as  well  as  simultaneously  considering  both  the 
scheduling  of  assets  on  legs  and  the  scheduling  of  movement 
requirements  on  the  assets.  Unfortunat -ly ,  this  is  simply  not 
possible  to  accomplish  in  an  optimal  manner. 


First,  there  is  a  data  problem.  For  long  deployments  it 
is  very  unlikely  that  the  movements  of  the  assets  or  the 
movement  requirements  could  be  predicted  with  any 
reasonable  accuracy. 
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Second,  even  if  this  is  possible  if  individual  ships  and 
planes  are  considered,  the  mathematical  models  required 
to  optimize  the  mode  assignment  are  orders-of-magnitude 
beyond  what  can  be  solved  with  today's  technology. 


The  question  then  becomes  "what  levels  of  approximation  can 
be  made  to  generate  models  which  would  be  useful  in  making 
mode  decisions  and  which  can  be  solved  in  a  reasonable  amount 
of  time?"  The  DAP  provides  further  insights  into  this 
question,  but  does  not  as  yet  provide  what  appears  to  be  an 
acceptable  solution. 
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THE  DAP  STRUCTURE 


The  current  DAP  consists  of  a  controlling  module,  database 
management  system,  airlift  configuration  model,  sealift 
configuration  model,  a  movement  requirement  assignment  model 
(the  MRMATE  model) ,  and  a  reporting  module. 

As  with  any  "first  version",  the  DAP  has  some  "rough  edges." 
This  section  will  focus  on  some  possibilities  for  improving 
the  DAP. 

3 . 1  Microcomputer  Selection 

The  IBM  PC  microcomputer  environment  was  a  reasonable  choice 
for  the  implementation  of  the  DAP.  There  are  a  wide  range  of 
high  quality  software  and  peripherals  for  the  IBM  PC  which 
provide  flexibility  in  implementing  the  DAP. 

USTRANSCOM  should  consider  migrating  the  DAP  to  a  386  class 
machine  with  a  VGA  monitor.  The  faster  machine  (preferably 
20-25  mh)  will  cause  the  DAP  to  run  approximately  two  and  one- 
half  to  three  times  faster  than  the  current  AT.  The  VGA 
monitor  will  accommodate  better  graphics  as  the  DAP  evolves. 
It  would  also  be  attractive  to  use  a  portable  computer  which 
would  allow  USTRANSCOM  personnel  to  take  the  DAP  "on  the 


road . " 


3 . 2  Flow  Control 


The  DAP  has  a  driver  which  controls  the  flow  through  the 
system.  The  current  level  of  control  is  awkward  for  the  user. 
Additional  effort  could  be  applied  to  enhance  the  flexibility 
to  move  through  the  system  according  to  user  desires  and 
needs . 

3.3  Database  Management  and  Reporting 

The  selection  of  dBASE  III  Plus  was  a  good  idea.  dBASE  allows 
great  flexibility  in  designing  a  database  management  system 
on  an  IBM  microcomputer.  Some  of  the  screens  are,  at  times, 
"user  unfriendly.”  Sometimes,  required  inputs  and  responses 
are  a  mystery. 

The  DAP  currently  offers  some  capability  for  examining  the 
data.  It  would  be  nice  to  provide  an  enhanced  capability  to 
view  the  data  in  various  ways  according  to  the  user's  needs. 

The  dBASE  screens  and  functions  should  be  redesigned  to 
provide  greater  flexibility. 

3 . 4  Graphics 

The  graphics  in  the  DAP  needs  considerable  rework.  This  is 
an  opportunity  for  USTRANSCOM  to  use  the  DAP  to  impress  poten¬ 
tial  users  and  it  should  not  be  wasted.  More  than  anything 
else,  this  sets  the  tone  of  the  DAP. 


Considerable  effort  should  be  applied  to  improving  and 
enhancing  the  graphics.  Graphics  packages  such  as  GSS  or 


Metawindows  are  excellent  choices  for  a  graphics  •'platform" 
on  which  a  set  of  new  screens  can  be  designed.  Graphics 
similar  to  that  in  the  MTMC  STRADS  prototype  should  be 
considered  for  inclusion  in  the  DAP. 


3 . 5  User  Interface 

The  user  interface  for  the  DAP  consists  of  utilizing  certain 
input  fields  under  dBASE.  The  DAP,  following  the  design  of 
MODES,  was  not  intended  as  an  interactive  system.  Without 
major  effort,  it  is  unlikely  that  an  interactive  component  can 
be  added  to  the  DAP.  Yet  this  feature  is  essential  to  make 
the  system  work  in  the  field. 


3.6  Optimization  Models 

The  DAP  contains  three  major  optimization  models.  Two  of  the 
models  (airlift  and  sealift  configuration)  are  new.  The  third 
(MR  assignment)  is  the  MRMATE  model  from  MODES. 


3.6.1 


Airlift 


The  airlift  model  appears  to  have  some  significant  weaknesses 
which  are  being  addressed  by  Oak  Ridge  National  Laboratories 
(ORNL) .  This  model  should  definitely  be  replaced  as  a  result 
of  that  effort. 
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3.6.2  Sealift 

Georgia  Tech  PDRC  Report  No.  88-05  discussed  alternative 
approaches  for  sealift  modelling.  It  appears  that  the  DAP  can 
be  significantly  improved  by  implementing  an  approach  similar 
to  one  described  in  that  report. 

3.6.3  MR  Assignment 

The  MR  assignment  model  is  the  MRMATE  model  from  MODES  (and 
SCOPE) .  This  model  has  consistently  been  the  most  robust 
MODES  component.  Given  realistic  asset  conf igure^tions,  MRMATE 
provides  realistic  MR  mode  assignments  and  schedules. 


« 


MRMATE  will  run  reasonably  fast  for  small  problems;  however, 
as  USTRANSCOM  attempts  to  prototype  larger  scenarios  MRMATE 
will  begin  to  increase  dramatically  in  execution  time  on  a  PC. 
In  such  circumstances  consideration  needs  to  be  given  to 
speeding  up  MRMATE  where  possible.  Fortunately,  some  of  the 
basic  assumptions  for  the  DAP  permit  MRMATE  to  be  decomposed 
into  a  set  of  smaller  problems  which  taken  together  will  run 
faster. 


To  keep  the  size  and  complexity  manageable  it  was  decided  that 
each  logistics  planning  region  (LPR)  would  be  serviced  by  only 
a  limited  number  of  POEs.  A  table  inside  the  DAP  specifies 


13 


this  connectivity.  This  limited  connectivity  can  be  exploited 
to  advantage  in  decomposing  the  KRMATE  model. 

3 . 6 . 3 . 1  Decomposing  MRMATE 

To  illustrate  the  decomposition  principle  consider  the  LPR/POE 
connectivity  implied  by  the  following  table. 

LPR/POE  Connectivity  Table 
POE 

1  2 

1 
L 

P  2 
R 

3 

LPRs  1  and  2  are  served  by  POE  1,  while  LPR  3  is  served  by  POE 
2.  In  this  case,  it  is  possible  to  solve  the  MRMATE  problem 
as  two  smaller  problems.  One  of  the  problems  contains  LPRs 
1  and  2  together  with  POE  1.  The  other  problem  contains  LPR 
3  and  POE  2. 

3 . 6 . 3 . 2  Advantages  of  MRMATE  Decomposition 

Figure  1  illustrates  the  iruntime  advantages  of  decomposing  the 
MRMATE  problem.  In  the  figure,  XI  is  the  size  (LPRs  plus 
POEs)  of  one  component,  while  X2  is  the  size  of  the  other 
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Problem  Size 

Figur*  1  MRMATE  Runtimes  by  Problem  Size 

component.  For  example,  component  1  might  be  LPR3  and  POE  1 
above,  and  component  2  the  rest.  The  curve,  an  upward  bow, 
depicts  generally  how  runtime  increases  with  problem  size. 
Reading  horizontally  from  the  curve  at  XI  one  gets  a  runtime 
of  Yl.  The  runtime  for  X2  is  Y2.  Therefore,  if  the  com¬ 
ponents  are  solved  separately,  ignoring  any  overhead,  the 
total  time  would  be  the  value  Y1+Y2.  However,  if  the  problem 
were  solved  all  together  the  runtime  would  be  Y3. 
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3 . 7  Integration 

The  DAP  system  has  a  design  which  achieves  a  strong  linear 
flow.  Through  redesign  and  enhancement  of  the  control  module 
it  is  possible  to  achieve  greater  flexibility  in  maneuvering 
among  the  components  of  the  system. 


I 
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RECOMMENDATIONS 


4.1  Continuous  Flow  Assumption 

The  DAP  should  be  enhanced  to  take  advantage  of  the  experience 
gain^^with  the  MODES  model  and  the  research  resulting  from 
this  experieh^': The  fundamental  approximations  made  in  the 
MODES  model  assumed  continuous  transportation^e.g. ,  instead 
of  considering  discrete  ships  and  planes^^ssigned  to  each  leg, 
the  model  considered  "stons  of  Capacity"  and  "mtons  of 
capacity"  assigned  to  each  leg) .  While  this  allowed  the 
entire  problem  to  be  captured  in  an  optimization  model,  there 
were  serious  difficulties  interpreting  the  results  for  the 
very  small  deployments  used  in  testing.  This  seems  unavoid¬ 
able  when  the  model  is  used  in  a  batch  environment  (as  opposed 
to  an  interactive  environment) . 


The  major  problem  with  MODES  occurs  in  small  deployments  when 
the  model  results  do  not  translate  into  whole  ship  loads. 
While  there  are  other  options  which  might  be  considered  (e.g. , 
multi-commodity  flow  models) ,  it  seems  apparent  that  all 
tractable  optimization  models,  in  order  to  simultaneously 
consider  both  air  and  sea  and  the  scheduling  of  assets  on  legs 
and  the  scheduling  of  movement  requirements  on  the  assets, 
would  require  the  assumption  of  continuous  transportation  and 
hence  would  suffer  from  the  same  problem. 


Based  on  the  experience  to  date,  the  continuous  flow  assump¬ 
tion  can  be  retained  provided  that  the  system  contains 
substantial  interactivity.  It  does  not  seem  attractive  to 
model  discrete  ships  and  planes  for  anything  but  the  very 
short  term  scheduling  and  routing  problems.  For  the  medium 
and  long  term  problems,  the  data  resolution  cannot  support 
stronger  assumptions  than  continuous  flow.  In  addition,  the 
heuristic/simulation  approaches  which  treat  discrete  (individ¬ 
ual)  ships  and  planes  suffer  from  very  limited  "look  ahead" 
because  of  the  time  constraints  under  which  the  system  must 
operate . 

4.2  MR  Scheduling 

Given  that  the  mode  decision  problem  cannot  be  addressed  in 
one  piece,  the  logical  partition  is  to  have  one  model  to 
handle  the  scheduling  of  assets  on  legs  and  another  model  to 
handle  the  scheduling  of  movement  requirements  on  the  assets. 
In  spirit  this  is  what  MODES  did  with  LIFTCAP  scheduling  the 
assets  and  MRHATE  scheduling  the  movement  requirements.  This 
partition  is  also  utilized  in  the  DAP  with  HRMATE  scheduling 
the  movement  requirements  and  a  heuristic  procedure  to 
schedule  the  assets.  In  both  cases,  the  MRMATE  segment  works 
very  well. 

Based  on  all  of  the  Georgia  Tech  research,  together  with  the 
implementations  of  MODES  and  the  DAP,  the  MRMATE  model  is  both 
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robust  and  computationally  tractable.  It  appears  highly 
unlikely  that  any  superior  procedure  can  be  developed  for  the 
problem  of  scheduling  the  movement  requirements.  Therefore, 
MRMATE  should  remain  a  central  component  of  any  future 
enhanced  DAP. 

4 . 3  Asset  Scheduling 

The  problem  in  both  MODES  and  the  DAP  is  with  asset  schedul¬ 
ing.  Based  on  recent  Georgia  Tech  research,  MODES  can  be 
significantly  improved;  but  it  is  only  useful  as  a  decision 
aid  in  an  interactive  system.  It  is  not  likely  that  an  all 
inclusive  optimization  model  can  be  developed  which  will 
overcome  the  problems  that  MODES  has  as  a  result  of  the 
continuous  transportation  approximation. 

4.4  "One  Pass"  vs  Optimization 

Evaluation  of  the  DAP  suggests  that  any  "one-pass"  concept, 
(i.e.,  make  one  schedule  of  assets  and  one  assignment  of 
movement  requirements)  such  as  that  used  in  the  DAP  will  have 
some  serious  problems  in  terms  of  the  quality  of  the  output. 
It  is  not  likely  that  the  quality  of  such  an  approach  can  ever 
be  made  acceptable  outside  an  interactive  environment. 

A  reasonable  compromise  between  the  optimization  approach  used 
in  MODES  and  the  one-pass  heuristic  used  in  the  DAP  is  to  use 
MRMATE  for  movement  requirement  assignment  together  with  a  new 


model  for  asset  assignment  which  incorporates  user  interac¬ 
tivity  and  handles  ships  as  discrete  units.  A  variant  of 
LIFTCAP  could  still  be  used  for  the  air  assignment  provided 
that  the  user  could  interactively  control  the  solution  and 
force  integer  answers  where  necessary  (i.e.,  on  legs  with  very 
few  assets) .  This  would  also  allow  some  limited  but  produc¬ 
tive  iteration  between  the  movement  requirement  assignment 
and  the  asset  scheduling. 

For  sealift,  the  basic  DAP  models  would  focus  on  determining 
and  displaying  aggregate  time-phased  transportation  require¬ 
ments  (needs) ;  and  the  user  would  utilize  this  information  in 
conjunction  with  other  interactive  aids  to  develop  ship 
schedules  and  routes  which  integrate  with  the  air  scheduling 
in  MRMATE. 

This  approach  is  a  variation  of  the  concept  recommended  in  the 
original  SCOPE  design  (Georgia  Tech  PDRC  Report  82-22  and  84- 
09) .  It  would  retain  the  elements  of  MODES  and  the  DAP  which 
have  been  proven  to  work  and  provide  an  enhanced  solution  to 
the  remaining  problems  based  on  lessons  learned  from  the  MODES 
and  DAP  experiences. 
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